Managing Request Handlers
To
provide support for various Web application technologies, the
architecture of IIS allows for enabling and disabling request handlers.
Request handlers are programs that can process Web requests and
generate responses that are then returned to clients. Web servers and
Web applications can be configured with their own sets of request
handlers, based on the types of content that must be supported. For
example, a Web application might be configured to support static
content (such as HTML) as well as ASP.NET Web pages.
The
primary benefit is that Web developers can choose the technologies that
are most useful for their tasks. However, there is a drawback from a
security standpoint. When IIS is configured with multiple request
handlers, the security attack surface is increased. A vulnerability in
any of the enabled request handlers can result in unauthorized access
or related issues. Therefore, it is recommended that systems
administrators enable only those request handlers that they plan to
use. In this section, you’ll learn how to enable and disable request
handlers.
|
Anil Desai
Web
developers and systems administrators tend to grant far too many
permissions on their Web servers. Their motivation is simple: it’s just
easier to provide complete access for all features and settings. That
way, it’s unlikely that you’ll miss some strange requirement. Often,
systems administrators don’t understand the complexities of Web
application security, and Web developers don’t appreciate the
importance of minimizing the attack surface of production Web servers.
The end result is security that is less than ideal, and increased risk
of unauthorized access. So what’s the solution?
The
most important aspect of determining ideal security settings is
communication. Server administrators should ask Web application
developers for a list of specific requirements for applications running
in production. A pre-production checklist that includes details about
intended users, required IIS handlers, authentication requirements, and
code access security requirements is a good start. Web developers
should understand the importance of minimizing exposure of services and
of reducing execution permissions for their applications. To ensure
that these goals are being met, both teams can develop tests that
validate the configuration from functional and security standpoints.
Overall,
Web developers and Web server administrators tend to have different
technical backgrounds and areas of expertise. This is a positive
difference as long as both groups understand the benefits of
implementing production server security.
|
Understanding Handler Mappings
When the Web server receives a request, IIS uses the definition of handler mappings to determine which request handler to use. A handler mapping includes the following information:
Verb
HTTP requests include verbs that define the type of request being made.
The two most common verbs are GET, which is used to obtain information
from the Web server, and POST, which can also include information sent
from the client browser to the Web server.
Request extension
Web servers commonly return a wide array of content types. The most
common types of information are standard HTML pages and images such as
.jpg and .gif files. IIS can use the file extension information from
the HTTP request to determine which type of content must be processed.
For example, the default file extension for ASP.NET Web pages is .aspx.
Requests for .aspx pages are mapped automatically to the
ASP.NET request handler. Most Web development platforms have their own
conventions for extensions. It is also possible to create new
extensions and provide the appropriate mappings for them.
Handler information
The handler mapping includes details related to the specific request
handler that IIS should call based on the verb and request extension.
This information can be provided in different ways, including a full
path to an executable or as the name of a program that is designed to
handle the request.
In
addition to specific handler mappings based on these settings, IIS
provides the ability to return content by using a default handler. The
StaticFile handler mapping is configured to respond to requests that do
not map to an existing file. The specific response will be based on the
settings for the Web application. If a default document is specified
for the Web application or virtual directory, that document will be
returned if a file is not specified in the URL. For example, a request
to http://Server1.contoso.com/TestSite will result automatically in the return of the default.htm document (if one exists).
If
a default document does not exist or the feature is disabled, the
StaticFile handler checks whether directory browsing is enabled. If it
is, a listing of the contents of the folder is returned to the
requester. Finally, if neither of these methods is able to complete the
request, the user will receive an error stating that the request is
forbidden. The complete error message is HTTP Error 403.14, The Web
Server Is Configured To Not List The Contents Of This Directory. (See Figure 12.)
Note: Local vs. remote error messages
For
security purposes, IIS is configured to provide one type of error
message to Web users who access the server from the local computer, and
another type of error message to users who access it remotely. This is
done to maintain security: potentially sensitive information is not
exposed to remote Web browser users, but useful troubleshooting
information is still provided to systems administrators and Web
developers.
